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such pc.seticipntion to occur, host software and harcl-.varo items will need to 
00 developed or modified; also some special l.Y,? programs will likely need 
to bo rewritten to accommodate the host. 

woiik is now underway to define the nature and magnitude of the tasks 
ahead. Several reasons make it necessary to start this work now. First, 
estimates are needed of the resources required on the part of ARPA and its 
contractors of elapsed time, man power, and money in order to get the hosts 
in order. Also solid background and experience with host problems must be 
developed by ARPA* and its contractors so as to provide early interaction with 
the network design, especially in evaluating the development of the IMP and 
the network protocols. 

Finally, time is needed to convey the knowledge gained to those ARPA 
contractors joining the network at a sligh'ciy later time. 

I I .Major Areas of .Activity 
A . General 

Three major problem areas must be tackled. First, effort must be 
devoted to the development of mechanisms whereby executive programs of 
different hosts can communicate. .Also effort must be directed to tne develop 
ment of mechanisms for effecting communication between user programs. 
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I s is I’.oco^iLU'y to examine tr.o nature o* tno llo'.'. 1 oi centre* *nici 
motion between host computers. Such is concerned with thu high 

level coordir.ation of the host to host process, us opposed to the processes 
carried cue by the user oriented programs. These higher level processes 
flight coal with: 1) the movement of files, 2'j the control of rer.'.otely 
located program, 3) the screening of attempted uses of the network, 4) the 
execution of login and logout procedures, if they are used, 5) controlling 
the access and other uses of a host's resources by the network, 6) validation 
of identifications, and 7) execution of procedures for coping with network 
faults. 

To permit communication between executive programs, some form of 
protocol should be established encompassing message formats, acknowledgement 
procedures, codes, and object names. It is not clear at the moment whether 
a common network protocol need be used, or whether many such protocols will 
exist, say one per host pair. 

C. Communication Between User Programs 

A major problem at the user program level arises from the large 
variety of terminal devices that might need to be served by any given user 
program. Thus there are teletypewriter devices using hardcopy, CRTs using 
i. it j ’n: * i < t 1 i! )(t X , (.’i;'lV. ilSi-ii;/ continuous i'i*t i‘i ■: i i: i U;, ! ij'.nt pun:., 1.: i i i] i •-( s , n. i c e, 

and contact closures. in many instances Liu* user is provided a 1. llic A-rmunal 
with some form of very rapid feedback in response to an action generated by 
him. The possible sources of these feedback signals must be examined. 
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D. Network To stir..? 


Two goals can be identified 


■;o network testing. First, 


the tests should demonstrate the operational characteristics of the network 
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environment. These tests should exercise all the network 


functions and measure the various network response times. The other objective 
is to aid in the identification of faulty elements during the period of initial 
debugging. The network elements of concern here are: 1) at the host- 
hardware ' (e . g . , at the interface v :h the IMP), and programs (e.g., the 
monitor, the communication executive), 2) at the I.MP-hardware, programs 
(contractor supplied and host supplied), and with the communication facilities- 
modems, transmission circuits, and switches. 


The approaches used to effect the testing should be such as to minimize 
the time required of the host computer and to minimize the effort required 
of the AhPA contractor personnel (e.g., programmers, engineers). These 
constraints make it desirable much testing to proceed using only the IMPs 
and the communication facilities. The remainder of the tests should be 
efficient in their use of any of tho host's facilities. 
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By April 1 the tasks set for the Working Group should be essentially 
completed, in particular, the IMP should have been defined. I believe the 
Working Group should continue to function beyond April 1, and be expanded to 
include a representative of the University of California at Berkeley (UCB). 
The major objective.of the Group, would be to solve those problems required 
to make their host computers working elements of the ARPA network by about 
January 1969^ At that time their IMPS should have been delivered, installed 
and debugged. The organizations represented by the Group, excepting RAND, 
are responsible for the first hosts to join the network. 

This activity of the Group should have a significant impact upon the 
other users of the network, and upon the contractor responsible for the IMPs. 
For one thing, the Group would be identifying and solving problems that the 
other users will encounter later. The work of the Group should be fully 
documented and available to these other users to use or ignore, as they see 
fit. Also, the Group could provide, through ARPA, an interaction with the 
IMP development: providing answers to problems raised by the contractor, 
indicating the need for modifications to the initial IMP design, and evaluat¬ 
ing the IMP as it progresses. 

The Group might well devote the four month period, April through July 
1968, to an examination of their mutual problems, studying alternative 
solutions, and finally selecting the solutions they wish to implement. Every 
consideration would be given to selecting those solutions that would fit into 
the entire network. Consultations with other network users would be vigor¬ 
ously pursued by the entire Group during that period. 
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In the succeeding five months, August through December 1968, each site 
would undertake to implement their chosen solutions, involving the writing 
and debugging of host programs, of specialized IMP programs, and the install¬ 
ation and debugging of interface hardware for the host . The members would 
appraise the group of new problems encountered, and approaches taken. 

At the outset each Group member would review, for all the other members, 
the important features of his host computer's software, hardware, operating 
system, and general rules of procedure. An initial inventory list would be 
constructed by each member of those resources of his host system that could 
be-used by others of the-network. Such a list, always subject to revision 
by the member, would account for the programs, storage media and volume, 
peripheral devices, etc. The inventory doubtless will be less than the total 
resources of the member's host system. 

Broad gauge policies would be mutually developed, among all the members 
of the group, regarding the rules of usage, and protocols between monitors, 
supervisors, operating systems, or whatever. A suggested set of topics for 
study includes: 

(1) The control of resources 

a) Control of access to a resource 

b) For those entitled to use a resource, the 
allocations (e.g. space and time) to be 
used 

c) User verification mechanisms 

(2) The elements of information to be exchanged between host 

operating systems 

(3) Mechanisms for naming system elements 

a) Users 

b) Files 

c) Programs 

d) Miscellaneous items 

e) Reserved names 


(4)• Acknowledgements between hosts for closed loop operations 


(5) Exception and fault conditions 

a) Crashes 

b) Recoveries 

c) Self-protection 

(6) Message protocols, formats, and codes 
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Very truly yours, 


Elmer B. Shapiro 
Sr. Research Engineer 
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